<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"><head>






<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta http-equiv="Content-Style-Type" content="text/css">
<link href="dhcp-options.5_fichiers/man.css" type="text/css" rel="stylesheet">
<link href="http://www.daemon-systems.org/man/index.html" rel="Index"><title>dhcp-options.5</title></head><body>

<pre>dhcpd-options(5)                                              dhcpd-options(5)



<strong>NAME</strong>
       dhcp-options - Dynamic Host Configuration Protocol options

<strong>DESCRIPTION</strong>
       The  Dynamic  Host  Configuration protocol allows the client to receive
       <strong>options</strong> from the DHCP server describing the network  configuration  and
       various  services that are available on the network.   When configuring
       <strong><a href="http://www.daemon-systems.org/man/dhcpd.8.html">dhcpd(8)</a></strong> or <strong><a href="http://www.daemon-systems.org/man/dhclient.8.html">dhclient(8)</a></strong> <strong>,</strong> options must often be declared.   The  syntax
       for  declaring  options,  and the names and formats of the options that
       can be declared, are documented here.

<strong>REFERENCE:</strong> <strong>OPTION</strong> <strong>STATEMENTS</strong>
       DHCP <span class="underline">option</span> statements always start with the <span class="underline">option</span>  keyword,  followed
       by  an option name, followed by option data.  The option names and data
       formats are described below.   It  is  not  necessary  to  exhaustively
       specify  all  DHCP  options  -  only  those options which are needed by
       clients must be specified.

       Option data comes in a variety of formats, as defined below:

       The <strong>ip-address</strong> data type can  be  entered  either  as  an  explicit  IP
       address  (e.g.,  239.254.197.10)  or  as  a  domain  name  (e.g.,  haa-
       gen.isc.org).  When entering a domain name, be sure  that  that  domain
       name resolves to a single IP address.

       The  <strong>int32</strong>  data  type  specifies a signed 32-bit integer.   The <strong>uint32</strong>
       data type specifies an unsigned 32-bit integer.   The <strong>int16</strong> and  <strong>uint16</strong>
       data  types specify signed and unsigned 16-bit integers.   The <strong>int8</strong> and
       <strong>uint8</strong> data types specify signed and unsigned 8-bit integers.   Unsigned
       8-bit integers are also sometimes referred to as octets.

       The  <strong>text</strong>  data  type  specifies  an  NVT  ASCII  string, which must be
       enclosed in double quotes - for example, to specify a root-path option,
       the syntax would be

       option root-path "10.0.1.4:/var/tmp/rootfs";

       The  <strong>domain-name</strong>  data  type  specifies  a  domain name, which must not
       enclosed in double quotes.   This data type is not used for any  exist-
       ing DHCP options.   The domain name is stored just as if it were a text
       option.

       The <strong>flag</strong> data type specifies a boolean value.   Booleans can be  either
       true or false (or on or off, if that makes more sense to you).

       The  <strong>string</strong>  data type specifies either an NVT ASCII string enclosed in
       double quotes, or a series of octets specified  in  hexadecimal,  sepa-
       rated by colons.   For example:

         option dhcp-client-identifier "CLIENT-FOO";
       or
         option dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f;

<strong>SETTING</strong> <strong>OPTION</strong> <strong>VALUES</strong> <strong>USING</strong> <strong>EXPRESSIONS</strong>
       Sometimes  it's  helpful  to  be able to set the value of a DHCP option
       based on some value that the client has sent.   To do this, you can use
       expression  evaluation.   The <strong><a href="http://www.daemon-systems.org/man/dhcp-eval.5.html">dhcp-eval(5)</a></strong> manual page describes how to
       write expressions.   To assign  the  result  of  an  evaluation  to  an
       option, define the option as follows:

         <strong>option</strong> <span class="underline">my-option</span> <strong>=</strong> <span class="underline">expression</span> <strong>;</strong>

       For example:

         option hostname = binary-to-ascii (16, 8, "-",
                                            substring (hardware, 1, 6));

<strong>STANDARD</strong> <strong>DHCP</strong> <strong>OPTIONS</strong>
       The documentation for the various options mentioned below is taken from
       the latest IETF draft document on DHCP  options.   Options  not  listed
       below  may  not  yet  be  implemented,  but  it is possible to use such
       options by defining them in the configuration  file.   Please  see  the
       DEFINING  NEW  OPTIONS heading later in this document for more informa-
       tion.

       Some of the options documented here are automatically generated by  the
       DHCP  server  or by clients, and cannot be configured by the user.  The
       value of such an option can be used in the configuration  file  of  the
       receiving DHCP protocol agent (server or client), for example in condi-
       tional expressions. However, the value of the option cannot be used  in
       the  configuration  file  of  the  sending  agent, because the value is
       determined only <span class="underline">after</span> the configuration file has been processed. In the
       following  documentation,  such options will be shown as "not user con-
       figurable"

       The standard options are:

       <strong>option</strong> <strong>all-subnets-local</strong> <span class="underline">flag</span><strong>;</strong>

         This option specifies whether or not the client may assume  that  all
         subnets  of  the  IP network to which the client is connected use the
         same MTU as the subnet  of  that  network  to  which  the  client  is
         directly connected.  A value of true indicates that all subnets share
         the same MTU.  A value of false means that the client  should  assume
         that  some subnets of the directly connected network may have smaller
         MTUs.

       <strong>option</strong> <strong>arp-cache-timeout</strong> <span class="underline">uint32</span><strong>;</strong>

         This option specifies the timeout in seconds for ARP cache entries.

       <strong>option</strong> <strong>bootfile-name</strong> <span class="underline">text</span><strong>;</strong>

         This option is used to identify a bootstrap file.   If  supported  by
         the  client,  it should have the same effect as the <strong>filename</strong> declara-
         tion.  BOOTP clients are unlikely to support this option.  Some  DHCP
         clients will support it, and others actually require it.

       <strong>option</strong> <strong>boot-size</strong> <span class="underline">uint16</span><strong>;</strong>

         This  option  specifies the length in 512-octet blocks of the default
         boot image for the client.

       <strong>option</strong> <strong>broadcast-address</strong> <span class="underline">ip-address</span><strong>;</strong>

         This option specifies the broadcast address in use  on  the  client's
         subnet.   Legal  values for broadcast addresses are specified in sec-
         tion 3.2.1.3 of STD 3 (RFC1122).

       <strong>option</strong> <strong>cookie-servers</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>...  ]<strong>;</strong>

         The cookie server option specifies a list of RFC 865  cookie  servers
         available  to the client.  Servers should be listed in order of pref-
         erence.

       <strong>option</strong> <strong>default-ip-ttl</strong> <span class="underline">uint8;</span>

         This option specifies the default time-to-live that the client should
         use on outgoing datagrams.

       <strong>option</strong> <strong>default-tcp-ttl</strong> <span class="underline">uint8</span><strong>;</strong>

         This option specifies the default TTL that the client should use when
         sending TCP segments.  The minimum value is 1.

       <strong>option</strong> <strong>dhcp-client-identifier</strong> <span class="underline">string</span><strong>;</strong>

         This option can be used to specify a DHCP client identifier in a host
         declaration,  so  that  dhcpd  can  find  the host record by matching
         against the client identifier.

         Please be aware that some DHCP clients, when configured  with  client
         identifiers  that  are  ASCII  text, will prepend a zero to the ASCII
         text.   So you may need to write:

              option dhcp-client-identifier "\0foo";

         rather than:

              option dhcp-client-identifier "foo";

       <strong>option</strong> <strong>dhcp-lease-time</strong> <span class="underline">uint32</span><strong>;</strong>

         This option is used in a client request (DHCPDISCOVER or DHCPREQUEST)
         to allow the client to request a lease time for the IP address.  In a
         server reply (DHCPOFFER), a DHCP server uses this option  to  specify
         the lease time it is willing to offer.

         This option is not directly user configurable in the server; refer to
         the  <span class="underline">max-lease-time</span>  and   <span class="underline">default-lease-time</span>   server   options   in
         <strong><a href="http://www.daemon-systems.org/man/dhcpd.conf.5.html">dhcpd.conf(5)</a>.</strong>

       <strong>option</strong> <strong>dhcp-max-message-size</strong> <span class="underline">uint16</span><strong>;</strong>

         This  option,  when sent by the client, specifies the maximum size of
         any response that the server sends to the client.   When specified on
         the  server,  if  the  client  did  not  send a dhcp-max-message-size
         option, the size specified on the server is used.    This  works  for
         BOOTP as well as DHCP responses.

       <strong>option</strong> <strong>dhcp-message</strong> <span class="underline">text</span><strong>;</strong>

         This option is used by a DHCP server to provide an error message to a
         DHCP client in a DHCPNAK message in the event of a failure. A  client
         may  use  this  option  in  a DHCPDECLINE message to indicate why the
         client declined the offered parameters.

         This option is not user configurable.

       <strong>option</strong> <strong>dhcp-message-type</strong> <span class="underline">uint8</span><strong>;</strong>

         This option, sent by both client and server, specifies  the  type  of
         DHCP  message  contained  in  the DHCP packet. Possible values (taken
         directly from RFC2132) are:

                      1     DHCPDISCOVER
                      2     DHCPOFFER
                      3     DHCPREQUEST
                      4     DHCPDECLINE
                      5     DHCPACK
                      6     DHCPNAK
                      7     DHCPRELEASE
                      8     DHCPINFORM

         This option is not user configurable.

       <strong>option</strong> <strong>dhcp-option-overload</strong> <span class="underline">uint8</span><strong>;</strong>

         This option is used to indicate  that  the  DHCP  'sname'  or  'file'
         fields  are  being  overloaded by using them to carry DHCP options. A
         DHCP server inserts this  option  if  the  returned  parameters  will
         exceed the usual space allotted for options.

         If  this option is present, the client interprets the specified addi-
         tional fields after  it  concludes  interpretation  of  the  standard
         option fields.

         Legal values for this option are:

                      1     the 'file' field is used to hold options
                      2     the 'sname' field is used to hold options
                      3     both fields are used to hold options

         This option is not user configurable.


       <strong>option</strong> <strong>dhcp-parameter-request-list</strong> <span class="underline">uint16</span><strong>;</strong>

         This  option,  when  sent  by the client, specifies which options the
         client wishes the server to  return.    Normally,  in  the  ISC  DHCP
         client, this is done using the <span class="underline">request</span> statement.   If this option is
         not specified by the client, the DHCP  server  will  normally  return
         every  option  that  is  valid in scope and that fits into the reply.
         When this option is specified on the server, the server  returns  the
         specified  options.    This  can  be  used  to force a client to take
         options that it hasn't requested, and it can also be used  to  tailor
         the response of the DHCP server for clients that may need a more lim-
         ited set of options than those the server would normally return.

       <strong>option</strong> <strong>dhcp-rebinding-time</strong> <span class="underline">uint32</span><strong>;</strong>

         This option specifies the number of seconds from the  time  a  client
         gets  an address until the client transitions to the REBINDING state.

         This option is not user configurable.


       <strong>option</strong> <strong>dhcp-renewal-time</strong> <span class="underline">uint32</span><strong>;</strong>

         This option specifies the number of seconds from the  time  a  client
         gets an address until the client transitions to the RENEWING state.

         This option is not user configurable.


       <strong>option</strong> <strong>dhcp-requested-address</strong> <span class="underline">ip-address</span><strong>;</strong>

         This option is used by the client in a DHCPDISCOVER to request that a
         particular IP address be assigned.

         This option is not user configurable.


       <strong>option</strong> <strong>dhcp-server-identifier</strong> <span class="underline">ip-address</span><strong>;</strong>

         This option is used in DHCPOFFER and DHCPREQUEST  messages,  and  may
         optionally  be  included  in  the DHCPACK and DHCPNAK messages.  DHCP
         servers include this option in the DHCPOFFER in order  to  allow  the
         client  to  distinguish  between  lease offers.  DHCP clients use the
         contents of the 'server identifier' field as the destination  address
         for  any DHCP messages unicast to the DHCP server.  DHCP clients also
         indicate which of several lease offers is being accepted by including
         this option in a DHCPREQUEST message.

         The value of this option is the IP address of the server.

         This option is not directly user configurable. See the <span class="underline">server-identi-</span>
         <span class="underline">fier</span> server option in <span class="underline"><a href="http://www.daemon-systems.org/man/dhcpd.conf.5.html">dhcpd.conf(5)</a>.</span>


       <strong>option</strong> <strong>domain-name</strong> <span class="underline">text</span><strong>;</strong>

         This option specifies the domain name that  client  should  use  when
         resolving hostnames via the Domain Name System.

       <strong>option</strong> <strong>domain-name-servers</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>...  ]<strong>;</strong>

         The domain-name-servers option specifies a list of Domain Name System
         (STD 13, RFC 1035) name servers available  to  the  client.   Servers
         should be listed in order of preference.

       <strong>option</strong> <strong>extensions-path</strong> <span class="underline">text</span><strong>;</strong>

         This  option  specifies  the  name  of  a  file containing additional
         options to be interpreted according to  the  DHCP  option  format  as
         specified in RFC2132.

       <strong>option</strong> <strong>finger-server</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>... ]<strong>;</strong>

         The Finger server option specifies a list of Finger servers available
         to the client.  Servers should be listed in order of preference.

       <strong>option</strong> <strong>font-servers</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>...  ]<strong>;</strong>

         This option specifies a list of X Window System Font  servers  avail-
         able  to the client. Servers should be listed in order of preference.

       <strong>option</strong> <strong>host-name</strong> <span class="underline">string</span><strong>;</strong>

         This option specifies the name of the client.  The name  may  or  may
         not  be qualified with the local domain name (it is preferable to use
         the domain-name option to specify the domain name).  See RFC 1035 for
         character set restrictions.  This option is only honored by <strong>dhclient-</strong>
         <strong>script(8)</strong> if the hostname for the client machine is not set.

       <strong>option</strong> <strong>ieee802-3-encapsulation</strong> <span class="underline">flag</span><strong>;</strong>

         This option specifies whether or not the client should  use  Ethernet
         Version  2  (RFC  894)  or IEEE 802.3 (RFC 1042) encapsulation if the
         interface is an Ethernet.  A value of false indicates that the client
         should  use  RFC  894  encapsulation.  A value of true means that the
         client should use RFC 1042 encapsulation.

       <strong>option</strong> <strong>ien116-name-servers</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>...  ];

         The ien116-name-servers option specifies  a  list  of  IEN  116  name
         servers  available  to the client.  Servers should be listed in order
         of preference.

       <strong>option</strong> <strong>impress-servers</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>...  ]<strong>;</strong>

         The impress-server option specifies a list of Imagen Impress  servers
         available  to the client.  Servers should be listed in order of pref-
         erence.

       <strong>option</strong> <strong>interface-mtu</strong> <span class="underline">uint16</span><strong>;</strong>

         This option specifies the MTU to use on this interface.   The minimum
         legal value for the MTU is 68.

       <strong>option</strong> <strong>ip-forwarding</strong> <span class="underline">flag</span><strong>;</strong>

         This  option  specifies  whether  the  client should configure its IP
         layer for packet forwarding.  A value of false means disable IP  for-
         warding, and a value of true means enable IP forwarding.

       <strong>option</strong> <strong>irc-server</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>... ]<strong>;</strong>

         The  IRC  server  option specifies a list of IRC servers available to
         the client.  Servers should be listed in order of preference.

       <strong>option</strong> <strong>log-servers</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>...  ]<strong>;</strong>

         The log-server option specifies a list of  MIT-LCS  UDP  log  servers
         available  to the client.  Servers should be listed in order of pref-
         erence.

       <strong>option</strong> <strong>lpr-servers</strong> <span class="underline">ip-address</span>  [<strong>,</strong> <span class="underline">ip-address</span>...  ]<strong>;</strong>

         The LPR server option specifies a  list  of  RFC  1179  line  printer
         servers  available  to the client.  Servers should be listed in order
         of preference.

       <strong>option</strong> <strong>mask-supplier</strong> <span class="underline">flag</span><strong>;</strong>

         This option specifies whether or not the  client  should  respond  to
         subnet mask requests using ICMP.  A value of false indicates that the
         client should not respond.  A value of true  means  that  the  client
         should respond.

       <strong>option</strong> <strong>max-dgram-reassembly</strong> <span class="underline">uint16</span><strong>;</strong>

         This  option  specifies  the  maximum  size  datagram that the client
         should be prepared to reassemble.  The minimum legal value is 576.

       <strong>option</strong> <strong>merit-dump</strong> <span class="underline">text</span><strong>;</strong>

         This option specifies the path-name of a file to which  the  client's
         core  image  should  be  dumped in the event the client crashes.  The
         path is formatted as a character string consisting of characters from
         the NVT ASCII character set.

       <strong>option</strong> <strong>mobile-ip-home-agent</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>... ]<strong>;</strong>

         This  option  specifies  a  list of IP addresses indicating mobile IP
         home agents available to the client.   Agents  should  be  listed  in
         order  of  preference,  although normally there will be only one such
         agent.

       <strong>option</strong> <strong>nds-context</strong> <span class="underline">string</span><strong>;</strong>

         The nds-context option specifies the  name  of  the  initial  Netware
         Directory Service for an NDS client.

       <strong>option</strong> <strong>nds-servers</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>... ]<strong>;</strong>

         The  nds-servers  option  specifies  a  list  of  IP addresses of NDS
         servers.

       <strong>option</strong> <strong>nds-tree-name</strong> <span class="underline">string</span><strong>;</strong>

         The nds-tree-name option specifies NDS tree name that the NDS  client
         should use.

       <strong>option</strong> <strong>netbios-dd-server</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>...  ]<strong>;</strong>

         The  NetBIOS  datagram  distribution server (NBDD) option specifies a
         list of RFC 1001/1002 NBDD servers listed in order of preference.

       <strong>option</strong> <strong>netbios-name-servers</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>...]<strong>;</strong>

         The NetBIOS name  server  (NBNS)  option  specifies  a  list  of  RFC
         1001/1002  NBNS name servers listed in order of preference.   NetBIOS
         Name Service is currently more commonly referred to as  WINS.    WINS
         servers can be specified using the netbios-name-servers option.

       <strong>option</strong> <strong>netbios-node-type</strong> <span class="underline">uint8</span><strong>;</strong>

         The NetBIOS node type option allows NetBIOS over TCP/IP clients which
         are configurable to be configured as described in RFC 1001/1002.  The
         value  is  specified  as  a  single octet which identifies the client
         type.

         Possible node types are:


         <span class="underline">1</span>    B-node: Broadcast - no WINS

         <span class="underline">2</span>    P-node: Peer - WINS only

         <span class="underline">4</span>    M-node: Mixed - broadcast, then WINS

         <span class="underline">8</span>    H-node: Hybrid - WINS, then broadcast

       <strong>option</strong> <strong>netbios-scope</strong> <span class="underline">string</span><strong>;</strong>

         The NetBIOS scope option specifies  the  NetBIOS  over  TCP/IP  scope
         parameter  for the client as specified in RFC 1001/1002. See RFC1001,
         RFC1002, and RFC1035 for character-set restrictions.

       <strong>option</strong> <strong>nis-domain</strong> <span class="underline">text</span><strong>;</strong>

         This option specifies the name  of  the  client's  NIS  (Sun  Network
         Information Services) domain.  The domain is formatted as a character
         string consisting of characters from the NVT ASCII character set.

       <strong>option</strong> <strong>nis-servers</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>...  ]<strong>;</strong>

         This option specifies a list of IP addresses indicating  NIS  servers
         available  to the client.  Servers should be listed in order of pref-
         erence.

       <strong>option</strong> <strong>nisplus-domain</strong> <span class="underline">text</span><strong>;</strong>

         This option specifies the name of  the  client's  NIS+  domain.   The
         domain  is  formatted  as a character string consisting of characters
         from the NVT ASCII character set.

       <strong>option</strong> <strong>nisplus-servers</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>...  ]<strong>;</strong>

         This option specifies a list of IP addresses indicating NIS+  servers
         available  to the client.  Servers should be listed in order of pref-
         erence.

       <strong>option</strong> <strong>nntp-server</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>... ]<strong>;</strong>

         The NNTP server option specifies a list of NNTP servesr available  to
         the client.  Servers should be listed in order of preference.

       <strong>option</strong> <strong>non-local-source-routing</strong> <span class="underline">flag</span><strong>;</strong>

         This  option  specifies  whether  the  client should configure its IP
         layer to allow forwarding of datagrams with non-local  source  routes
         (see  Section  3.3.5 of [4] for a discussion of this topic).  A value
         of false means disallow forwarding of such datagrams, and a value  of
         true means allow forwarding.

       <strong>option</strong> <strong>ntp-servers</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>...  ]<strong>;</strong>

         This  option  specifies  a  list  of IP addresses indicating NTP (RFC
         1035) servers available to the client.  Servers should be  listed  in
         order of preference.

       <strong>option</strong> <strong>nwip-domain</strong> <span class="underline">string</span><strong>;</strong>

         The  name  of  the  NetWare/IP domain that a NetWare/IP client should
         use.

       <strong>option</strong> <strong>nwip-suboptions</strong> <span class="underline">string</span><strong>;</strong>

         A sequence of suboptions for NetWare/IP clients  -  see  RFC2242  for
         details.    Normally  this  option is set by specifying specific Net-
         Ware/IP suboptions - see the NETWARE/IP SUBOPTIONS section  for  more
         information.

       <strong>option</strong> <strong>path-mtu-aging-timeout</strong> <span class="underline">uint32</span><strong>;</strong>

         This option specifies the timeout (in seconds) to use when aging Path
         MTU values discovered by the mechanism defined in RFC 1191.

       <strong>option</strong> <strong>path-mtu-plateau-table</strong> <span class="underline">uint16</span> [<strong>,</strong> <span class="underline">uint16</span>...  ]<strong>;</strong>

         This option specifies a table of MTU sizes  to  use  when  performing
         Path MTU Discovery as defined in RFC 1191.  The table is formatted as
         a list of 16-bit unsigned integers, ordered from smallest to largest.
         The minimum MTU value cannot be smaller than 68.

       <strong>option</strong> <strong>perform-mask-discovery</strong> <span class="underline">flag</span><strong>;</strong>

         This option specifies whether or not the client should perform subnet
         mask discovery using ICMP.  A  value  of  false  indicates  that  the
         client should not perform mask discovery.  A value of true means that
         the client should perform mask discovery.

       <strong>option</strong> <strong>policy-filter</strong> <span class="underline">ip-address</span> <span class="underline">ip-address</span>
                         [<strong>,</strong> <span class="underline">ip-address</span> <span class="underline">ip-address</span>...]<strong>;</strong>

         This option specifies policy filters for  non-local  source  routing.
         The filters consist of a list of IP addresses and masks which specify
         destination/mask pairs with which to filter incoming source routes.

         Any source routed datagram whose next-hop address does not match  one
         of the filters should be discarded by the client.

         See STD 3 (RFC1122) for further information.

       <strong>option</strong> <strong>pop-server</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>... ]<strong>;</strong>

         The  POP3 server option specifies a list of POP3 servers available to
         the client.  Servers should be listed in order of preference.

       <strong>option</strong> <strong>resource-location-servers</strong> <span class="underline">ip-address</span>
                                     [<strong>,</strong> <span class="underline">ip-address</span>...]<strong>;</strong>

         This option specifies a list of RFC  887  Resource  Location  servers
         available  to the client.  Servers should be listed in order of pref-
         erence.

       <strong>option</strong> <strong>root-path</strong> <span class="underline">text</span><strong>;</strong>

         This option specifies the path-name that contains the  client's  root
         disk.   The  path  is  formatted  as a character string consisting of
         characters from the NVT ASCII character set.

       <strong>option</strong> <strong>router-discovery</strong> <span class="underline">flag</span><strong>;</strong>

         This option specifies  whether  or  not  the  client  should  solicit
         routers  using the Router Discovery mechanism defined in RFC 1256.  A
         value of false indicates that the client should  not  perform  router
         discovery.   A  value  of  true  means that the client should perform
         router discovery.

       <strong>option</strong> <strong>router-solicitation-address</strong> <span class="underline">ip-address</span><strong>;</strong>

         This option specifies the address to which the client should transmit
         router solicitation requests.

       <strong>option</strong> <strong>routers</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>...  ]<strong>;</strong>

         The  routers  option  specifies a list of IP addresses for routers on
         the client's subnet.  Routers should be listed in  order  of  prefer-
         ence.

       <strong>option</strong> <strong>slp-directory-agent</strong> <span class="underline">boolean</span> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>... ]<strong>;</strong>

         This  option  specifies  two  things: the IP addresses of one or more
         Service Location Protocol Directory Agents, and whether  the  use  of
         these addresses is mandatory.   If the initial boolean value is true,
         the SLP agent should just use the IP addresses given.   If the  value
         is  false, the SLP agent may additionally do active or passive multi-
         cast discovery of SLP agents (see RFC2165 for details).

         Please note that in this option and the slp-service-scope option, the
         term  "SLP Agent" is being used to refer to a Service Location Proto-
         col agent running on a machine that is  being  configured  using  the
         DHCP protocol.

         Also,  please  be  aware that some companies may refer to SLP as NDS.
         If you have an NDS directory agent whose address you need to  config-
         ure, the slp-directory-agent option should work.

       <strong>option</strong> <strong>slp-service-scope</strong> <span class="underline">boolean</span> <span class="underline">text</span><strong>;</strong>

         The  Service  Location  Protocol  Service  Scope Option specifies two
         things: a list of service scopes for SLP, and whether the use of this
         list  is  mandatory.   If  the initial boolean value is true, the SLP
         agent should only use the list of scopes  provided  in  this  option;
         otherwise,  it  may use its own static configuration in preference to
         the list provided in this option.

         The text string should be a comma-separated list of scopes  that  the
         SLP  agent  should  use.    It  may be omitted, in which case the SLP
         Agent will use the aggregated list of scopes of all directory  agents
         known to the SLP agent.

       <strong>option</strong> <strong>smtp-server</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>... ]<strong>;</strong>

         The  SMTP server option specifies a list of SMTP servers available to
         the client.  Servers should be listed in order of preference.

       <strong>option</strong> <strong>static-routes</strong> <span class="underline">ip-address</span> <span class="underline">ip-address</span>
                         [<strong>,</strong> <span class="underline">ip-address</span> <span class="underline">ip-address</span>...]<strong>;</strong>

         This option specifies a list of static routes that the client  should
         install  in its routing cache.  If multiple routes to the same desti-
         nation are specified, they are listed in descending order  of  prior-
         ity.

         The  routes consist of a list of IP address pairs.  The first address
         is the destination address, and the second address is the router  for
         the destination.

         The  default  route  (0.0.0.0) is an illegal destination for a static
         route.  To specify the default route, use the <strong>routers</strong> option.   Also,
         please note that this option is not intended for classless IP routing
         - it does not include a subnet mask.   Since classless IP routing  is
         now  the most widely deployed routing standard, this option is virtu-
         ally useless, and is not implemented  by  any  of  the  popular  DHCP
         clients, for example the Microsoft DHCP client.

       <strong>option</strong> <strong>streettalk-directory-assistance-server</strong> <span class="underline">ip-address</span>
                                                  [<strong>,</strong> <span class="underline">ip-address</span>...]<strong>;</strong>

         The  StreetTalk Directory Assistance (STDA) server option specifies a
         list of STDA servers available to  the  client.   Servers  should  be
         listed in order of preference.

       <strong>option</strong> <strong>streettalk-server</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>... ]<strong>;</strong>

         The  StreetTalk  server option specifies a list of StreetTalk servers
         available to the client.  Servers should be listed in order of  pref-
         erence.

       <strong>option</strong> <strong>subnet-mask</strong> <span class="underline">ip-address</span><strong>;</strong>

         The  subnet mask option specifies the client's subnet mask as per RFC
         950.  If no subnet mask option is provided anywhere in  scope,  as  a
         last  resort  dhcpd will use the subnet mask from the subnet declara-
         tion for the network on which an address is being assigned.  However,
         <span class="underline">any</span>  subnet-mask  option declaration that is in scope for the address
         being assigned will override the subnet mask specified in the  subnet
         declaration.

       <strong>option</strong> <strong>subnet-selection</strong> <span class="underline">string</span><strong>;</strong>

         Sent  by  the client if an address is required in a subnet other than
         the one that would  normally  be  selected  (based  on  the  relaying
         address  of  the  connected subnet the request is obtained from). See
         RFC3011. Note that the option number used by this server is 118; this
         has  not  always  been the defined number, and some clients may use a
         different value. Use of this option should be  regarded  as  slightly
         experimental!

       This option is not user configurable in the server.


       <strong>option</strong> <strong>swap-server</strong> <span class="underline">ip-address</span><strong>;</strong>

         This specifies the IP address of the client's swap server.

       <strong>option</strong> <strong>tcp-keepalive-garbage</strong> <span class="underline">flag</span><strong>;</strong>

         This  option  specifies  whether  or  not  the client should send TCP
         keepalive messages with an octet of garbage  for  compatibility  with
         older  implementations.   A  value  of false indicates that a garbage
         octet should not be sent. A value of true indicates  that  a  garbage
         octet should be sent.

       <strong>option</strong> <strong>tcp-keepalive-interval</strong> <span class="underline">uint32</span><strong>;</strong>

         This  option  specifies the interval (in seconds) that the client TCP
         should wait before sending a keepalive message on a  TCP  connection.
         The  time is specified as a 32-bit unsigned integer.  A value of zero
         indicates that the client should not generate keepalive  messages  on
         connections unless specifically requested by an application.

       <strong>option</strong> <strong>tftp-server-name</strong> <span class="underline">text</span><strong>;</strong>

         This  option  is  used to identify a TFTP server and, if supported by
         the client, should have the same effect as the  <strong>server-name</strong>  declara-
         tion.   BOOTP clients are unlikely to support this option.  Some DHCP
         clients will support it, and others actually require it.

       <strong>option</strong> <strong>time-offset</strong> <span class="underline">int32</span><strong>;</strong>

         The time-offset option specifies the offset of the client's subnet in
         seconds from Coordinated Universal Time (UTC).

       <strong>option</strong> <strong>time-servers</strong> <span class="underline">ip-address</span> [, <span class="underline">ip-address</span>...  ]<strong>;</strong>

         The  time-server  option  specifies  a  list  of RFC 868 time servers
         available to the client.  Servers should be listed in order of  pref-
         erence.

       <strong>option</strong> <strong>trailer-encapsulation</strong> <span class="underline">flag</span><strong>;</strong>

         This  option specifies whether or not the client should negotiate the
         use of trailers (RFC 893 [14]) when using the ARP protocol.  A  value
         of  false  indicates that the client should not attempt to use trail-
         ers.  A value of true means that the client  should  attempt  to  use
         trailers.

       <strong>option</strong> <strong>uap-servers</strong> <span class="underline">text</span><strong>;</strong>

         This option specifies a list of URLs, each pointing to a user authen-
         tication  service  that  is  capable  of  processing   authentication
         requests encapsulated in the User Authentication Protocol (UAP).  UAP
         servers can accept either HTTP 1.1 or SSLv3 connections.  If the list
         includes  a  URL  that  does not contain a port component, the normal
         default port is assumed (i.e., port 80 for  http  and  port  443  for
         https).  If the list includes a URL that does not contain a path com-
         ponent, the path /uap is assumed.   If more than one URL is specified
         in this list, the URLs are separated by spaces.

       <strong>option</strong> <strong>user-class</strong> <span class="underline">string</span><strong>;</strong>

         This  option is used by some DHCP clients as a way for users to spec-
         ify identifying information to the client.   This can be  used  in  a
         similar  way  to the vendor-class-identifier option, but the value of
         the option is specified by the user, not the  vendor.    Most  recent
         DHCP  clients  have  a way in the user interface to specify the value
         for this identifier, usually as a text string.

         <strong>option</strong> <strong>vendor-class-identifier</strong> <span class="underline">string</span><strong>;</strong>

            This option is used by some DHCP clients to  identify  the  vendor
            type  and possibly the configuration of a DHCP client.  The infor-
            mation is a string of bytes whose contents  are  specific  to  the
            vendor  and  are not specified in a standard.   To see what vendor
            class identifier clients are sending, you can write the  following
            in your DHCP server configuration file:

            set vendor-string = option vendor-class-identifier;

            This  will result in all entries in the DHCP server lease database
            file for clients that sent vendor-class-identifier options  having
            a set statement that looks something like this:

            set vendor-string = "SUNW.Ultra-5_10";

            The  vendor-class-identifier  option  is normally used by the DHCP
            server to determine the options that are returned in  the  <strong>vendor-</strong>
            <strong>encapsulated-options</strong>  option.   Please see the VENDOR ENCAPSULATED
            OPTIONS section later in this manual page for further information.

         <strong>option</strong> <strong>vendor-encapsulated-options</strong> <span class="underline">string</span><strong>;</strong>

            The <strong>vendor-encapsulated-options</strong> option can contain either a single
            vendor-specific value or one or more  vendor-specific  suboptions.
            This  option is not normally specified in the DHCP server configu-
            ration file - instead, a vendor class is defined for each  vendor,
            vendor  class  suboptions are defined, values for those suboptions
            are defined, and the DHCP server  makes  up  a  response  on  that
            basis.

            Some  default  behaviours for well-known DHCP client vendors (cur-
            rently, the Microsoft Windows 2000  DHCP  client)  are  configured
            automatically,  but  otherwise  this must be configured manually -
            see the VENDOR ENCAPSULATED OPTIONS section later in  this  manual
            page for details.

         <strong>option</strong> <strong>www-server</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>... ]<strong>;</strong>

            The WWW server option specifies a list of WWW servers available to
            the client.  Servers should be listed in order of preference.

         <strong>option</strong> <strong>x-display-manager</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>...  ]<strong>;</strong>

            This option specifies a list of systems that  are  running  the  X
            Window  System  Display  Manager  and are available to the client.
            Addresses should be listed in order of preference.

<strong>RELAY</strong> <strong>AGENT</strong> <strong>INFORMATION</strong> <strong>OPTION</strong>
       An IETF draft, draft-ietf-dhc-agent-options-11.txt, defines a series of
       encapsulated  options  that a relay agent can add to a DHCP packet when
       relaying it to the DHCP server.   The  server  can  then  make  address
       allocation  decisions  (or  whatever other decisions it wants) based on
       these options.   The server also returns these options in  any  replies
       it  sends  through the relay agent, so that the relay agent can use the
       information in these options for delivery or accounting purposes.

       The current draft defines two options.   To reference these options  in
       the  dhcp server, specify the option space name, "agent", followed by a
       period, followed by the option name.   It is  not  normally  useful  to
       define values for these options in the server, although it is permissi-
       ble.   These options are not supported in the client.

       <strong>option</strong> <strong>agent.circuit-id</strong> <span class="underline">string</span><strong>;</strong>

         The circuit-id suboption encodes an  agent-local  identifier  of  the
         circuit  from  which a DHCP client-to-server packet was received.  It
         is intended for use by agents in relaying DHCP responses back to  the
         proper  circuit.    The format of this option is currently defined to
         be vendor-dependent, and will probably remain that way, although  the
         current  draft  allows  for  for the possibility of standardizing the
         format in the future.

       <strong>option</strong> <strong>agent.remote-id</strong> <span class="underline">string</span><strong>;</strong>

         The remote-id suboption encodes information about the remote host end
         of  a  circuit.   Examples of what it might contain include caller ID
         information, username information, remote ATM  address,  cable  modem
         ID, and similar things.   In principal, the meaning is not well-spec-
         ified, and it should generally be assumed to be an opaque object that
         is  administratively  guaranteed  to be unique to a particular remote
         end of a circuit.

<strong>THE</strong> <strong>CLIENT</strong> <strong>FQDN</strong> <strong>SUBOPTIONS</strong>
       The Client FQDN option, currently defined in the Internet Draft  draft-
       ietf-dhc-fqdn-option-00.txt  is  not  a  standard yet, but is in suffi-
       ciently wide use already that we have implemented it.   Due to the com-
       plexity  of  the  option  format, we have implemented it as a suboption
       space rather than a single option.   In general this option should  not
       be  configured  by  the  user - instead it should be used as part of an
       automatic DNS update system.

       <strong>option</strong> <strong>fqdn.no-client-update</strong> <span class="underline">flag</span><strong>;</strong>

         When the client sends this, if it is true, it means the  client  will
         not  attempt to update its A record.   When sent by the server to the
         client, it means that the client <span class="underline">should</span> <span class="underline">not</span> update its own A  record.

       <strong>option</strong> <strong>fqdn.server-update</strong> <span class="underline">flag</span><strong>;</strong>

         When  the  client sends this to the server, it is requesting that the
         server update its A record.   When sent by the server, it means  that
         the server has updated (or is about to update) the client's A record.

       <strong>option</strong> <strong>fqdn.encoded</strong> <span class="underline">flag</span><strong>;</strong>

         If true, this indicates that the domain name included in  the  option
         is encoded in DNS wire format, rather than as plain ASCII text.   The
         client normally sets this to false if it  doesn't  support  DNS  wire
         format  in  the FQDN option.   The server should always send back the
         same value that the client sent.   When this value is set on the con-
         figuration side, it controls the format in which the <span class="underline">fqdn.fqdn</span> subop-
         tion is encoded.

       <strong>option</strong> <strong>fqdn.rcode1</strong> <span class="underline">flag</span><strong>;</strong>

       <strong>option</strong> <strong>fqdn.rcode2</strong> <span class="underline">flag</span><strong>;</strong>

         These options specify the result of the updates  of  the  A  and  PTR
         records,  respectively,  and  are only sent by the DHCP server to the
         DHCP client.  The values of these fields are those defined in the DNS
         protocol specification.

       <strong>option</strong> <strong>fqdn.fqdn</strong> <span class="underline">text</span><strong>;</strong>

         Specifies  the  domain name that the client wishes to use.   This can
         be a fully-qualified domain name, or a single label.   If there is no
         trailing generally update that name in some locally-defined domain.

       <strong>option</strong> <strong>fqdn.hostname</strong> <span class="underline">--never</span> <span class="underline">set--</span><strong>;</strong>

         This  option  should  never be set, but it can be read back using the
         <strong>option</strong> and <strong>config-option</strong> operators in an expression, in which case it
         returns  the first label in the <strong>fqdn.fqdn</strong> suboption - for example, if
         the value of <strong>fqdn.fqdn</strong> is "foo.example.com.", then <strong>fqdn.hostname</strong> will
         be "foo".

       <strong>option</strong> <strong>fqdn.domainname</strong> <span class="underline">--never</span> <span class="underline">set--</span><strong>;</strong>

         This  option  should  never be set, but it can be read back using the
         <strong>option</strong> and <strong>config-option</strong> operators in an expression, in which case it
         returns all labels after the first label in the <strong>fqdn.fqdn</strong> suboption -
         for example, if the value of <strong>fqdn.fqdn</strong>  is  "foo.example.com.",  then
         <strong>fqdn.hostname</strong>  will  be  "example.com.".   If this suboption value is
         not set, it means that an unqualified  name  was  sent  in  the  fqdn
         option, or that no fqdn option was sent at all.

       If  you wish to use any of these suboptions, we strongly recommend that
       you refer to the Client FQDN option draft (or standard, when it becomes
       a  standard) - the documentation here is sketchy and incomplete in com-
       parison, and is just intended  for  reference  by  people  who  already
       understand the Client FQDN option specification.

<strong>THE</strong> <strong>NETWARE/IP</strong> <strong>SUBOPTIONS</strong>
       RFC2242  defines  a  set  of encapsulated options for Novell NetWare/IP
       clients.  To use these options in the dhcp server, specify  the  option
       space  name, "nwip", followed by a period, followed by the option name.
       The following options can be specified:

       <strong>option</strong> <strong>nwip.nsq-broadcast</strong> <span class="underline">flag</span><strong>;</strong>

         If true, the client should use the NetWare Nearest  Server  Query  to
         locate  a  NetWare/IP server.   The behaviour of the Novell client if
         this suboption is false, or is not present, is not specified.

       <strong>option</strong> <strong>nwip.preferred-dss</strong> <span class="underline">ip-address</span> [<strong>,</strong> <span class="underline">ip-address</span>... ]<strong>;</strong>

         This suboption specifies a list of up to five IP addresses,  each  of
         which  should  be  the  IP address of a NetWare Domain SAP/RIP server
         (DSS).

       <strong>option</strong> <strong>nwip.nearest-nwip-server</strong> <span class="underline">ip-address</span>
                                    [<strong>,</strong> <span class="underline">ip-address</span>...]<strong>;</strong>

         This suboption specifies a list of up to five IP addresses,  each  of
         which should be the IP address of a Nearest NetWare IP server.

       <strong>option</strong> <strong>nwip.autoretries</strong> <span class="underline">uint8</span><strong>;</strong>

         Specifies the number of times that a NetWare/IP client should attempt
         to communicate with a given DSS server at startup.

       <strong>option</strong> <strong>nwip.autoretry-secs</strong> <span class="underline">uint8</span><strong>;</strong>

         Specifies the number of seconds that a Netware/IP client should  wait
         between  retries  when  attempting to establish communications with a
         DSS server at startup.

       <strong>option</strong> <strong>nwip.nwip-1-1</strong> <span class="underline">uint8</span><strong>;</strong>

         If true, the NetWare/IP client should support NetWare/IP version  1.1
         compatibility.   This is only needed if the client will be contacting
         Netware/IP version 1.1 servers.

       <strong>option</strong> <strong>nwip.primary-dss</strong> <span class="underline">ip-address</span><strong>;</strong>

         Specifies the IP address of the Primary Domain SAP/RIP Service server
         (DSS)  for  this  NetWare/IP  domain.   The NetWare/IP administration
         utility uses this value as Primary DSS server when configuring a sec-
         ondary DSS server.

<strong>DEFINING</strong> <strong>NEW</strong> <strong>OPTIONS</strong>
       The  Internet  Systems  Consortium  DHCP  client and server provide the
       capability to define new options.   Each DHCP  option  has  a  name,  a
       code,  and  a  structure.    The  name  is  used by you to refer to the
       option.   The code is a number, used by the DHCP server and  client  to
       refer  to  an option.   The structure describes what the contents of an
       option looks like.

       To define a new option, you need to choose a name for it that is not in
       use  for  some  other  option  - for example, you can't use "host-name"
       because the DHCP protocol already defines a host-name option, which  is
       documented  earlier  in  this  manual page.   If an option name doesn't
       appear in this manual page, you can use it, but it's  probably  a  good
       idea  to  put some kind of unique string at the beginning so you can be
       sure that future options don't take your name.   For example, you might
       define  an  option,  "local-host-name", feeling some confidence that no
       official DHCP option name will ever start with "local".

       Once you have chosen a name, you must choose a  code.   For  site-local
       options,  all  codes between 128 and 254 are reserved for DHCP options,
       so you can pick any one of  these.   In  practice,  some  vendors  have
       interpreted  the protocol rather loosely and have used option code val-
       ues greater than 128 themselves.   There's no real way  to  avoid  this
       problem, but it's not likely to cause too much trouble in practice.

       The  structure  of  an  option is simply the format in which the option
       data appears.   The ISC DHCP server currently  supports  a  few  simple
       types,  like  integers, booleans, strings and IP addresses, and it also
       supports the ability to define arrays of  single  types  or  arrays  of
       fixed sequences of types.

       New options are declared as follows:

       <strong>option</strong> <span class="underline">new-name</span> <strong>code</strong> <span class="underline">new-code</span> <strong>=</strong> <span class="underline">definition</span> <strong>;</strong>

       The  values of <span class="underline">new-name</span> and <span class="underline">new-code</span> should be the name you have chosen
       for the new option and the  code  you  have  chosen.    The  <span class="underline">definition</span>
       should be the definition of the structure of the option.

       The following simple option type definitions are supported:

       <strong>BOOLEAN</strong>

       <strong>option</strong> <span class="underline">new-name</span> <strong>code</strong> <span class="underline">new-code</span> <strong>=</strong> <strong>boolean</strong> <strong>;</strong>

       An  option  of  type boolean is a flag with a value of either on or off
       (or true or false).   So an example use of the boolean type would be:

       option use-zephyr code 180 = boolean;
       option use-zephyr on;

       <strong>INTEGER</strong>

       <strong>option</strong> <span class="underline">new-name</span> <strong>code</strong> <span class="underline">new-code</span> <strong>=</strong> <span class="underline">sign</span> <strong>integer</strong> <span class="underline">width</span> <strong>;</strong>

       The <span class="underline">sign</span> token should either be blank, <span class="underline">unsigned</span> or <span class="underline">signed</span>.   The  width
       can  be  either  8,  16  or 32, and refers to the number of bits in the
       integer.   So for example, the following two lines show a definition of
       the sql-connection-max option and its use:

       option sql-connection-max code 192 = unsigned integer 16;
       option sql-connection-max 1536;

       <strong>IP-ADDRESS</strong>

       <strong>option</strong> <span class="underline">new-name</span> <strong>code</strong> <span class="underline">new-code</span> <strong>=</strong> <strong>ip-address</strong> <strong>;</strong>

       An option whose structure is an IP address can be expressed either as a
       domain name or as a dotted quad.  So the following is an example use of
       the ip-address type:

       option sql-server-address code 193 = ip-address;
       option sql-server-address sql.example.com;


       <strong>TEXT</strong>

       <strong>option</strong> <span class="underline">new-name</span> <strong>code</strong> <span class="underline">new-code</span> <strong>=</strong> <strong>text</strong> <strong>;</strong>

       An  option  whose  type is text will encode an ASCII text string.   For
       example:

       option sql-default-connection-name code 194 = text;
       option sql-default-connection-name "PRODZA";


       <strong>DATA</strong> <strong>STRING</strong>

       <strong>option</strong> <span class="underline">new-name</span> <strong>code</strong> <span class="underline">new-code</span> <strong>=</strong> <strong>string</strong> <strong>;</strong>

       An option whose type is a data string is essentially just a  collection
       of  bytes,  and  can  be specified either as quoted text, like the text
       type, or as a list of hexadecimal contents separated  by  colons  whose
       values must be between 0 and FF.   For example:

       option sql-identification-token code 195 = string;
       option sql-identification-token 17:23:19:a6:42:ea:99:7c:22;


       <strong>ENCAPSULATION</strong>

       <strong>option</strong> <span class="underline">new-name</span> <strong>code</strong> <span class="underline">new-code</span> <strong>=</strong> <strong>encapsulate</strong> <span class="underline">identifier</span> <strong>;</strong>

       An  option  whose  type is <strong>encapsulate</strong> will encapsulate the contents of
       the option space specified in <span class="underline">identifier</span>.    Examples  of  encapsulated
       options in the DHCP protocol as it currently exists include the vendor-
       encapsulated-options option,  the  netware-suboptions  option  and  the
       relay-agent-information option.

       option space local;
       option local.demo code 1 = text;
       option local-encapsulation code 197 = encapsulate local;
       option local.demo "demo";


       <strong>ARRAYS</strong>

       Options  can  contain  arrays  of any of the above types except for the
       text and data string types, which aren't currently supported in arrays.
       An example of an array definition is as follows:

       option kerberos-servers code 200 = array of ip-address;
       option kerberos-servers 10.20.10.1, 10.20.11.1;

       <strong>RECORDS</strong>

       Options  can  also  contain data structures consisting of a sequence of
       data types, which is sometimes called a record type.   For example:

       option contrived-001 code 201 = { boolean, integer 32, text };
       option contrived-001 on 1772 "contrivance";

       It's also possible to have options that  are  arrays  of  records,  for
       example:

       option new-static-routes code 201 = array of {
            ip-address, ip-address, ip-address, integer 8 };
       option static-routes
            10.0.0.0 255.255.255.0 net-0-rtr.example.com 1,
            10.0.1.0 255.255.255.0 net-1-rtr.example.com 1,
            10.2.0.0 255.255.224.0 net-2-0-rtr.example.com 3;


<strong>VENDOR</strong> <strong>ENCAPSULATED</strong> <strong>OPTIONS</strong>
       The  DHCP  protocol  defines  the   <strong>vendor-encapsulated-options</strong> option,
       which allows vendors to define their own  options  that  will  be  sent
       encapsulated  in  a  standard  DHCP option.   The format of the <strong>vendor-</strong>
       <strong>encapsulated-options</strong> option is either a series of bytes whose format is
       not  specified,  or  a sequence of options, each of which consists of a
       single-byte vendor-specific option  code,  followed  by  a  single-byte
       length,  followed  by  as  many  bytes  of data as are specified in the
       length (the length does not include itself or the option code).

       The value of this option can be set in one of two ways.   The first way
       is to simply specify the data directly, using a text string or a colon-
       separated list of hexadecimal values.   For example:

       option vendor-encapsulated-options
           2:4:AC:11:41:1:
           3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
           4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;

       The second way of setting the value of this option is to have the  DHCP
       server generate a vendor-specific option buffer.   To do this, you must
       do four things: define an option space, define  some  options  in  that
       option  space,  provide  values  for them, and specify that that option
       space  should  be  used  to  generate  the  <strong>vendor-encapsulated-options</strong>
       option.

       To define a new option space in which vendor options can be stored, use
       the option space statement:

       <strong>option</strong> <strong>space</strong> <span class="underline">name</span> <strong>;</strong>

       The name can then be used in option definitions, as  described  earlier
       in this document.   For example:

       option space SUNW;
       option SUNW.server-address code 2 = ip-address;
       option SUNW.server-name code 3 = text;
       option SUNW.root-path code 4 = text;

       Once  you  have defined an option space and the format of some options,
       you can set up scopes that define values for those options, and you can
       say  when  to  use  them.   For example, suppose you want to handle two
       different classes of clients.   Using the option space definition shown
       in  the  previous example, you can send different option values to dif-
       ferent clients based on the  vendor-class-identifier  option  that  the
       clients send, as follows:

       class "vendor-classes" {
         match option vendor-class-identifier;
       }

       option SUNW.server-address 172.17.65.1;
       option SUNW.server-name "sundhcp-server17-1";

       subclass "vendor-classes" "SUNW.Ultra-5_10" {
         vendor-option-space SUNW;
         option SUNW.root-path "/export/root/sparc";
       }

       subclass "vendor-classes" "SUNW.i86pc" {
         vendor-option-space SUNW;
         option SUNW.root-path "/export/root/i86pc";
       }

       As  you  can see in the preceding example, regular scoping rules apply,
       so you can define values that are global in the global scope, and  only
       define  values  that  are  specific  to a particular class in the local
       scope.   The <strong>vendor-option-space</strong> declaration tells the DHCP  server  to
       use  options  in the SUNW option space to construct the <strong>vendor-encapsu-</strong>
       <strong>lated-options</strong> option.

<strong>SEE</strong> <strong>ALSO</strong>
       <a href="http://www.daemon-systems.org/man/dhcpd.conf.5.html">dhcpd.conf(5)</a>,   <a href="http://www.daemon-systems.org/man/dhcpd.leases.5.html">dhcpd.leases(5)</a>,    <a href="http://www.daemon-systems.org/man/dhclient.conf.5.html">dhclient.conf(5)</a>,    <a href="http://www.daemon-systems.org/man/dhcp-eval.5.html">dhcp-eval(5)</a>,
       <a href="http://www.daemon-systems.org/man/dhcpd.8.html">dhcpd(8)</a>,    <a href="http://www.daemon-systems.org/man/dhclient.8.html">dhclient(8)</a>,   RFC2132,   RFC2131,   draft-ietf-dhc-agent-
       options-??.txt.

<strong>AUTHOR</strong>
       The Internet Systems Consortium DHCP Distribution was  written  by  Ted
       Lemon  under  a contract with Vixie Labs.  Funding for this project was
       provided through Internet Systems Consortium.  Information about Inter-
       net Systems Consortium can be found at <strong>http://www.isc.org.</strong>



                                                              dhcpd-options(5)
</pre>

<hr>

<div class="NetBSD-logo"><a href="http://www.netbsd.org/"><img alt="Site Driven by NetBSD" src="dhcp-options.5_fichiers/NetBSD.gif"></a></div>

</body></html>